Processing monitor system and method

ABSTRACT

Systems and methods for monitoring transaction data and providing an indication regarding a performance parameter to a payment processing entity. Transaction data associated with a plurality of transactions conducted during a time interval is received. A server computer determines that the received transaction data meets a threshold. It is further determined whether a previous indication that the threshold has been met was provided to a payment processing entity, the previous indication being associated with a plurality of previous transactions conducted during a previous time interval. If the previous indication was not provided, an indication that the threshold has been met is provided to the payment processing entity, the indication including information regarding a performance parameter of the payment processing entity.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.61/502,784, filed Jun. 29, 2011, entitled “MERCHANT MONITOR SERVICE,”which is herein incorporated by reference in its entirety for allpurposes.

BACKGROUND

The processing of electronic payment transactions typically requirescoordination between various payment processing entities such asmerchants, acquirers, acquirer processors, issuers, issuer processors,and payment processing networks. For example, the authorization of anelectronic transaction may involve the exchange of authorizationmessages amongst the payment processing entities. When a consumer makesa purchase at a merchant using a credit or debit card, the card may beswiped or scanned at an access device such as a point of sale terminalat the merchant location. The terminal may generate an authorizationrequest message that is routed through an acquirer and/or acquirerprocessor to a payment processing network. If the authorization requestmessage is rejected by the payment processing network, the merchant canbe notified and the transaction canceled. If the authorization requestmessage is accepted, the payment processing network can then route themessage to an issuer of the consumer's account and/or the issuer'sprocessor. The issuer or processor can then perform a number ofauthentication, authorization, and fraud detection steps to determinewhether to authorize the transaction. Upon making an authorizationdecision, an authorization response message can be transmitted by theissuer or processor back to the merchant—via the payment processingnetwork and the various payment processing entities—indicating whetherthe electronic payment transaction is approved or declined.

The payment processing entities that participate in electronictransaction processing may each rely on terminals, server computers,and/or other hardware and software to facilitate the exchange ofauthorization messages. From time to time, however, hardware andsoftware failures can occur that adversely affect the exchange ofauthorization messages amongst the payment processing entities. Forexample, if one or more of the payment processing entities is unable tocommunicate with the payment processing network or the other processingentities due to a failure, the issuer may not receive the authorizationrequest message, the merchant may not receive the authorization responsemessage, and the electronic transaction may not be completed. Hardwareand software failures can also result in authorization messages beinggenerated that contain invalid or corrupted data. Such messages mayresult in the payment processing network rejecting the message andcanceling the transaction, or the issuer declining an otherwise validand legitimate transaction. The above issues may affect all transactionsprocessed by a particular processing entity. In some circumstances,however, hardware and software failures may result in intermittentissues affecting only certain transactions. Such failures may be moredifficult to detect.

Existing computational solutions to the problem of detecting hardwareand software failures in electronic payment processing systems areinefficient, memory-intensive, and inaccurate. For example, paymentprocessing entities have historically relied on internal data monitoringmechanisms to detect hardware and software failures affecting theirability to receive, process, and transmit messages relating toelectronic payment transactions. As explained above, however, paymentprocessing issues experienced by one processing entity may be related toa hardware or software failure at another processing entity. Thus, someexisting solutions require the analysis of transaction data frommultiple sources in potentially disparate data formats. The aggregationand normalization of disparate data from multiple payment processingentities can be a time-consuming and memory-intensive process. Moreover,since certain failures result in only intermittent issues and are thusdifficult to detect, the data collected and analyzed by existingsolutions may not accurately portray the nature and source of thehardware or software failure.

One existing solution involves the monitoring of transactions at apayment processing network to detect an issuer's rejected transactionsand other processing issues that may indicate a hardware or softwarefailure at the issuer. If a potential failure is identified, a systemoperator at the payment processing network is provided with an alertmessage on a computer screen. This message may prompt the operator tocontact the issuer by telephone to bring the potential failure to theissuer's attention. In this solution, however, transactions for otherpayment processing entities such as merchants, acquirers, and processorsare not monitored. Moreover, the alerts provided are continuouslygenerated until the incidence of processing issues for the issuer fallsbelow a baseline level. Such continuous alert generation iscomputationally inefficient and memory-intensive.

Moreover, payment processing entities typically earn revenue on a pertransaction basis, and rejected or declined transactions often result inlost sales to merchants, lost switch fees to payment processingnetworks, and lost interchange revenue to issuers, acquirers, andprocessors. In other words, rejected or declined transactions may resultin lost revenue for all payment processing entities involved. Thus, itis essential that payment processing entities be made aware of hardwareand software problems as soon as possible so that repairs can be made ina timely manner.

Embodiments of the invention address the above problems, and otherproblems, individually and collectively.

SUMMARY

Embodiments of the invention are related to systems and methods formonitoring transaction data and providing an indication regarding aperformance parameter to a payment processing entity.

One embodiment of the invention is directed to a method comprisingreceiving transaction data associated with a plurality of transactionsconducted during a time interval. A server computer determines that thereceived transaction meets a threshold. It is further determined whethera previous indication that the threshold has been met was provided to apayment processing entity, the previous indication being associated witha plurality of previous transactions conducted during a previous timeinterval. If the previous indication was not provided, an indicationthat the threshold has been met is provided to the payment processingentity, the indication including information regarding a performanceparameter of the payment processing entity.

Another embodiment of the invention is directed to a server computercomprising a processor and a computer readable medium coupled to theprocessor. The computer readable medium comprises code executable by aprocessor for implementing a method comprising receiving transactiondata associated with a plurality of transactions conducted during a timeinterval, determining that the received transaction data meets athreshold, and determining whether a previous indication that thethreshold has been met was provided to a payment processing entity, theprevious indication being associated with a plurality of previoustransactions conducted during a previous time interval. If the previousindication was not provided, an indication that the threshold has beenmet is provided to the payment processing entity, the indicationincluding information regarding a performance parameter of the paymentprocessing entity.

Another embodiment of the invention is directed to a method comprisingtransmitting, by a payment processing entity, transaction dataassociated with a plurality of transactions conducted during a timeinterval to a server computer associated with a payment processingnetwork. The server computer determines that the transmitted transactiondata meets a threshold, and further determines whether a previousindication that the threshold has been met was provided to the paymentprocessing entity, the previous indication being associated with aplurality of previous transactions conducted during a previous timeinterval. If the previous indication was not provided, an indicationthat the threshold has been met is received from the server computer,the indication including information regarding a performance parameterof the payment processing entity.

These and other embodiments of the invention are described in furtherdetail below with reference to the Figures and the Detailed Description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a payment processing system according toan embodiment of the invention.

FIG. 2 shows a block diagram of a payment processing system according toan embodiment of the invention.

FIG. 3 shows a transaction data table according to an embodiment of theinvention.

FIG. 4 shows a threshold data table according to an embodiment of theinvention.

FIG. 5 shows an event data table according to an embodiment of theinvention.

FIG. 6 shows an event alert message according to an embodiment of theinvention.

FIG. 7 shows an event completion message according to an embodiment ofthe invention.

FIG. 8 illustrates a flow diagram showing a method for monitoringtransaction data and providing an indication regarding a performanceparameter to a payment processing entity according to an embodiment ofthe invention.

FIGS. 9A-9B show block diagrams of exemplary portable consumer devicesaccording to embodiments of the invention.

FIG. 10 shows a block diagram of an exemplary access device according toan embodiment of the invention.

FIG. 11 shows a block diagram of a computer apparatus according to anembodiment of the invention.

DETAILED DESCRIPTION

Prior to discussing embodiments of the invention, a further descriptionof some terms may be helpful in understanding embodiments of theinvention.

As used herein, a “transaction” may refer to a purchase of goods and/orservices, a withdrawal of funds, an electronic transfer of funds, or anyother transaction involving an account associated with a consumer. Atransaction can occur at a merchant location (e.g., at the point ofsale), at an automated teller machine (ATM), on the Internet, by phone,by mail, or in any other suitable context in which the transaction canbe processed electronically.

As used herein, “transaction data” may include data relating to atransaction as contained in an authorization message request message,contained in an authorization response message, and/or generated by theprocessing of an authorization message. For example, transaction datacan include a unique transaction identifier, transaction date and time,account number, transaction class code (e.g., credit, debit, ATM,prepaid, etc.), merchant code (e.g., MW, DBA, etc.), ATM code, acquirercode, acquirer processor code, issuer code (e.g., BIN, etc.), issuerprocessor code, authorization category code (e.g., approved, declined,rejected, etc.), one or more error codes, transaction amount (e.g.,settlement amount), cardholder or account holder information (e.g.,name, date of birth, address, phone number, etc.), card verificationvalue (CVV), expiration date, loyalty account information, and otherinformation relating to the transaction.

As used herein, a “payment processing entity” may include a merchant, anacquirer, an acquirer processor, an issuer, an issuer processor, apayment processing network, or any other entity that participates in theprocessing of electronic payment transactions. As used herein, a“merchant” may be an entity that engages in transactions and can sellgoods or services, and as used herein may also include an ATM. An“acquirer” may be a business entity (e.g., a commercial bank) that has abusiness relationship with a particular merchant or other entity. Asused herein, an “issuer” may be a business entity (e.g., a bank) thatmaintains financial accounts for consumers such as individuals,businesses, and other entities, and that may issue portable consumerdevices such as credit and debit cards to consumers. Some entities mayperform both issuer and acquirer functions. Embodiments of the inventionencompass such single entity issuer-acquirers. As used herein, a“payment processing network” may include data processing subsystems,networks, and operations used to support and deliver authorizationservices, exception file services, and clearing and settlement services.An exemplary payment processing network may include VisaNet™. Paymentprocessing networks such as VisaNet™ are able to process credit cardtransactions, debit card transaction, and other types of commercialtransactions. VisaNet™, in particular, includes a VIP system (VisaIntegrated Payments system) which processes authorization requests and aBase II system which performs clearing and settlement services. As usedherein, an “acquirer processor” may be an entity that processeselectronic payment transactions on behalf of an acquirer, or thatcooperates with an acquirer to process electronic payment transactions.As used herein, an “issuer processor” may be an entity that thatprocesses electronic payment transactions on behalf of an issuer, orthat cooperates with an issuer to process electronic paymenttransactions. An issuer processor may include data processingsubsystems, networks, and operations used to support and deliver variousservices such as network gateway, risk management, program management,authorization, exception file, and clearing and settlement services. Anexemplary issuer processor may include Visa DPS™.

As used herein, a “performance parameter” may include a parameterrelating to the processing of an electronic transaction that mayindicate a potential hardware or software failures at a paymentprocessing entity. For example, performance parameters can includeapproved transactions, declined transactions, rejected transactions,transaction processing time, transaction processing communicationerrors, or any other suitable parameter. As used herein, “approvedtransactions” may include transactions that are authorized by an issuer,payment processing network, or other payment processing entity. As usedherein, “declined transactions” may include transactions that are notauthorized by an issuer, payment processing network, or other paymentprocessing entity. A transaction may be declined due to insufficientfunds in a user's account, insufficient available credit, high risk offraud, authentication issues such as an invalid Personal IdentificationNumber (PIN), Card Verification Value (CVV), Dynamic Card VerificationValue (dCVV), cryptogram, or for other reasons. A transaction may alsobe declined due to invalid or corrupted transaction data (e.g., aninvalid or corrupted transaction ID, date, time, account number,transaction class code, merchant code, ATM code, acquirer code, acquirerprocessor code, issuer code, issuer processor code, authorizationcategory code, etc.) contained in an authorization message. As usedherein, “rejected transactions” may include transactions for which anauthorization request message or authorization response message isrejected for one or more reasons by a payment processing network orother payment processing entity. Authorization messages may be rejectedfor a number of reasons. For example, rejections may occur due toinvalid or corrupted transaction data (e.g., an invalid or corruptedtransaction ID, date, time, account number, transaction class code,merchant code, ATM code, acquirer code, acquirer processor code, issuercode, issuer processor code, authorization category code, etc.)contained in an authorization message. Rejections may also occur inresponse to invalid or corrupted authentication data included in thetransaction data such as an invalid Personal Identification Number(PIN), Card Verification Value (CVV), Dynamic Card Verification Value(dCVV), cryptogram, or other authentication issues. As used herein,“transaction processing time” may include the time required to process atransaction (i.e. the time that lapses from the transmission of anauthorization request message to the receipt of an authorizationresponse message at a merchant or ATM). Transaction processing time mayalso include the interval of time associated with exchanging anauthorization message between two or more payment processing entities.As used herein, “transaction processing communication errors” mayinclude any issue adversely affecting the ability of a paymentprocessing entity to send or receive authorization messages.

As used herein, an “indication” may include an alert, e-mail, textmessage, report, or any other electronic communication that provides apayment processing entity with information regarding a performanceparameter as defined above.

As used herein, an “authorization request message” may refer to a datamessage, or sequence of data messages, that requests an issuer of apayment account to authorize a transaction. An authorization requestmessage according to an embodiment of the invention may comply with ISO(International Organization for Standardization) 8583, which is astandard for systems that exchange electronic transactions made bycardholders using payment cards. An authorization request messageaccording to other embodiments may comply with other suitable standards.

As used herein, an “authorization response message” may refer to a datamessage, or sequence of data messages, that responds to a merchant'sand/or acquirer's request to authorize a transaction. An authorizationresponse message according to an embodiment of the invention may complywith ISO 8583, which, as described above, is a standard for systems thatexchange electronic transactions made by cardholders using paymentcards. An authorization response message according to other embodimentsmay comply with other suitable standards.

As used herein, a “server computer” may include a powerful computer orcluster of computers. For example, the server computer can be a largemainframe, a minicomputer cluster, or a group of servers functioning asa unit. In one example, the server computer may be a database servercoupled to a Web server. The server computer may be coupled to one ormore databases and may include any hardware, software, other logic, orcombination of the preceding for servicing the requests from one or moreclient computers. The server computer may comprise one or morecomputational apparatuses and may use any of a variety of computingstructures, arrangements, and compilations for servicing the requestsfrom one or more client computers.

Embodiments of the invention are related to systems and methods formonitoring transaction data and providing an indication regarding aperformance parameter to a payment processing entity. As explainedherein, received transaction data can be analyzed by a server computerto determine whether a threshold is met. If the threshold is met, anindication can be transmitted to the payment processing entity includinginformation regarding the performance parameter.

To illustrate, when a user makes a purchase at a merchant using aportable consumer device (e.g., a credit card, debit card, etc.), theuser may swipe their device at the merchant's POS terminal. If thetransaction is a debit transaction, the user may also enter a personalidentification number (PIN) at the POS terminal. The terminal may thentransmit an authorization request message to an acquirer, the messageincluding the user's PIN and other transaction data read from the user'sdevice. The acquirer may then route the authorization request message toa payment processing network which may forward the message to an issuer.The issuer may then perform a number of authorization, authentication,and fraud detection steps to make a decision regarding whether thetransaction is to be approved. If, for example, the PIN provided by theuser is invalid, or if the PIN was entered correctly by the user buttransmitted incorrectly due to a hardware or software problem with themerchant's POS terminal, the transaction may be declined. The issuer maythen transmit an authorization response message to the paymentprocessing network indicating that the transaction is not authorized.The payment processing network may then transmit the authorizationresponse message to the acquirer for forwarding back to the merchant.

The payment processing network may store a record of the declinedtransaction in a database that also includes records for a number ofprevious transactions conducted at the merchant and processed by thepayment processing network. Periodically, the payment processing networkmay analyze the stored transaction records against one or morethresholds. For example, the merchant may have established a thresholdof 25% for transactions declined due to an invalid PIN. Every 5 minutes,for example, the payment processing network may analyze the merchant'stransaction records to determine how many of the merchant's transactionsconducted in the last 5 minute time interval were declined due to aninvalid PIN code. If the stored records for the merchant indicate that10 transactions have been conducted at the merchant in the last 5 minutetime interval, and that 3 of the transactions (i.e. 30%) have beendeclined due to an invalid PIN, the payment processing network maytransmit an indication (e.g., an e-mail alert) to the merchantindicating that the threshold for transactions declined due to aninvalid PIN has been met. Such an alert may prompt the merchant toinvestigate possible hardware or software issues associated with the POSterminal that may be the source of the high occurrence of declinedtransactions. However, once the merchant has been notified of theproblem, the merchant may not want to receive redundant alerts every 5minutes indicating that the same problem is being detected by thepayment processing network. Thus, if the payment processing networkdetermines that the 25% threshold is met by declined transactionsconducted during subsequent 5 minute time intervals, the paymentprocessing network may decide not to send further alerts. Once thepayment processing network determines that subsequent transactions donot meet the 25% threshold, however, the payment processing network maytransmit an alert to the merchant indicating that the threshold is nolonger met, and that the problem appears to have been resolved.

In another illustration, upon receiving the authorization requestmessage described above, the payment processing network may forward themessage to the issuer and wait for an authorization response messagefrom the issuer. If no response is received from the issuer after adetermined period of time, the payment processing network may cancel thetransaction and transmit a message to the merchant (via the acquirer)indicating that the transaction is canceled due to communication issueswith the issuer. The payment processing network may store a record ofthe transaction in a database that also includes records for a number ofprevious transactions involving accounts associated with the issuer andprocessed by the payment processing network. Periodically, the paymentprocessing network may analyze the stored transaction records againstone or more thresholds. For example, the issuer may have established athreshold of 10% for transactions for which an authorization responsemessage is not received by the payment processing network. Every 2minutes, for example, the payment processing network may analyze theissuer's transaction records to determine how many of the issuer'stransactions conducted in the last 2 minute time interval did not resultin an authorization response message being received by the paymentprocessing network. If the stored records for the issuer indicate that10 transactions have been attempted on the issuer's accounts in a 2minute interval, and that 2 of the transactions (i.e. 20%) have beencanceled due to communication issues with the issuer, the paymentprocessing network may transmit an indication (e.g., an e-mail alert) tothe issuer indicating that the threshold for transactions canceled dueto communication issues has been met. The issuer may then investigatethe source of the communication problem. If, however, the paymentprocessing network determines that an alert was previously sent to theissuer due to canceled transactions in a previous time interval meetingthe 10% threshold, the payment processing network may decide not to senda redundant alert regarding the same issue. Instead, a further alert canbe sent indicating that the problem appears to be resolved once thepayment processing network determines that transactions in a subsequenttime interval do not meet the 10% threshold.

I. Exemplary Systems

FIG. 1 shows a block diagram of a payment processing system 100 that maybe used in an embodiment of the invention. System 100 may include a user110, a portable consumer device 112, a merchant computer 114, anacquirer computer 116, a payment processing network 118, and an issuercomputer 120. System 100 may also include an acquirer processor and/oran issuer processor (not shown).

The user 110 may be an individual, or an organization such as a businessthat is capable of purchasing goods or services. The user 110 may be amerchant, an employee of the merchant, or any other individual who hasaccess to the portable consumer device 112.

The portable consumer device 112 may be in any suitable form. Forexample, suitable portable consumer devices may be hand-held and compactso that it can fit into a user's wallet and/or pocket (e.g.,pocket-sized). The portable consumer device 112 may include a processor,and memory, input devices, and output devices, operatively coupled tothe processor. Specific examples of portable consumer devices includecellular or wireless phones, personal digital assistants (PDAs), pagers,portable computers, smart cards, and the like. The portable consumerdevice 112 can also be a debit device (e.g., a debit card), creditdevice (e.g., a credit card), or stored value device (e.g., a pre-paidor stored value card).

The merchant computer 114 may also have, or may receive communicationsfrom, an access device that can interact with the portable consumerdevice 112. The access devices may be in any suitable form. Examples ofaccess devices include point of sale (POS) devices, cellular phones,PDAs, personal computers (PCs), tablet PCs, handheld specializedreaders, set-top boxes, electronic cash registers, ATMs, virtual cashregisters, kiosks, security systems, access systems, and the like.

If the access device is a point of sale terminal, any suitable point ofsale terminal may be used including card or phone readers. The card orphone readers may include any suitable contact or contactless mode ofoperation. For example, exemplary readers can include RF (radiofrequency) antennas, magnetic stripe readers, etc. to interact with theportable consumer device 112.

In a purchase transaction, the user 110 may purchase goods or servicesat a merchant using a portable consumer device 112 such as a creditcard, debit card, prepaid card, etc. The user's portable consumer device112 may interact with an access device such as a POS terminal at themerchant. For example, the user 110 may take a debit card and swipe itthough an appropriate slot in the POS terminal.

Alternatively, the POS terminal may be a contactless reader, and theportable device 112 may be a contactless device such as a contactlesscard or phone. For example, the user 110 may take a contactless card ora phone and pass it in front of the contactless reader to transmitfinancial information stored on the device.

An authorization request message may be transmitted from the merchantcomputer 114 to the acquirer computer 116. After receiving theauthorization request message, the acquirer computer 116 may thentransmit the authorization request message to a payment processingnetwork 118. The payment processing network 118 may then either rejectthe authorization request message and cancel the transaction, or acceptthe authorization request message and forward it to an issuer computer120 associated with the portable consumer device 112.

After receiving the authorization request message, the issuer computer120 may perform a number of authorization, authentication, and frauddetection processes in order to make an authorization decision. Theissuer computer 120 may then generate and send an authorization responsemessage to the payment processing network 118 indicating whether or notthe transaction is approved. The payment processing network 118 maytransmit the authorization response message to the acquirer computer 116which may then transmit the authorization response message back to themerchant computer 114.

After the merchant computer 114 receives the authorization responsemessage, the access device communicatively connected to the merchantcomputer 114 may provide the authorization response message to the user110. The authorization response message may be displayed by the POSterminal, or may be printed out on a receipt.

Although the transaction described above is in the context of a purchasetransaction involving a merchant, the transaction may also be anautomated teller machine (ATM) transaction. Thus, the merchant computer114 as shown in FIG. 1 and described herein may alternatively include anATM.

At the end of the day, a normal clearing and settlement process may beconducted by the payment processing network 118 in cooperation with theissuer computer 120 and acquirer computer 116. A clearing process can bea process of exchanging financial details between an acquirer and anissuer to facilitate posting to a consumer's account and reconciliationof the consumer's settlement position. A settlement process can be aprocess of transferring funds between an acquirer and issuer. In someembodiments, authorization and settlement can occur simultaneously.

As described herein, the payment processing network 118 can store arecord of the transaction including transaction data contained in theauthorization request and response messages. The stored transaction datacan also include error codes generated by the payment processing network118 or included in the authorization messages. The above purchasetransaction can be repeated, and transactions can be conducted by aplurality of users utilizing a plurality of merchants, acquirers,issuer, and processors. Transactions can also be conducted using otherpayment processing networks in communication with the payment processingnetwork 118. Thus, the payment processing network 118 can storetransaction data for a plurality of transactions involving a pluralityof users, merchants, acquirers, issuers, processors, and paymentprocessing networks. The components and functionalities of a paymentprocessing system 200 according to various embodiments of the inventionare described in further detail below.

FIG. 2 shows a block diagram of a payment processing system 200 that maybe used in an embodiment of the invention. For simplicity of discussion,only one of each component is shown for several of the components. It isto be understood, however, that embodiments of the invention may includemore than one of each component. In addition, some embodiments of theinvention may include fewer than all of the components shown in FIG. 2.The various modules and databases in FIG. 2 may each be located withinthe payment processing network 118, outside the payment processingnetwork 118, and/or distributed at different locations. Further, thecomponents in FIG. 2 may communicate via any suitable communicationmedium such as the Internet using any suitable communication protocol.

System 200 may include the merchant computer 114 and the acquirercomputer 116 communicatively coupled to the merchant computer 114. Theuser 110 may purchase goods or services at a merchant associated withthe merchant computer 114 using the portable consumer device 110. Theacquirer computer 116 may communicate with the payment processingnetwork 118 which may be in communication with the issuer computer 120associated with an issuer of the portable consumer device 112. System200 may also include an acquirer processor computer and an issuerprocessor computer (not shown) associated with an acquire processor andissuer processor, respectively.

As shown in FIG. 2, the payment processing network 118 may include aserver computer 202 comprising an authorization module 204, an analyticsmodule 206, and an alert module 208. The various modules may be embodiedby computer code residing on a computer readable medium. The servercomputer 202 may be in communication with the issuer computer 120 andthe acquirer computer 116 by one or more communication channels. Forexample, authorization, clearing and settlement messages may beexchanged via any suitable communication medium such as the Internetusing any suitable communication protocol. In some embodiments of theinvention, an alternate communication channel 216 may be used totransmit indications to the various payment processing entities. Thealternative communication channel 216 may include the Internet, atelecommunications network, or any other suitable communication mediumusing any suitable communication protocol.

The server computer 202 may be operatively coupled to one or moredatabases, including a transaction database 210, a threshold database212, and an event database 214.

The authorization module 204 may perform a number of functions relatedto receiving and forwarding authorization request and authorizationresponse messages. Upon receiving an authorization request message fromthe acquirer computer 116, the authorization module 204 may forward theauthorization request message to the issuer computer 120. Upon receivingan authorization response message from the issuer computer 120, theauthorization module 204 may transmit the authorization response messageto the acquirer computer 116. The authorization module 204 may alsoextract transaction data from authorization request and responsemessages and transmit the extracted data to the transaction database 210for storage as a transaction record.

Error codes may be generated by the authorization module 204 if, forexample, an authorization message is rejected by the authorizationmodule 204. For example, rejections may occur due to invalid orcorrupted transaction data (e.g., an invalid or corrupted transactionID, date, time, account number, transaction class code, merchant code,ATM code, acquirer code, acquirer processor code, issuer code, issuerprocessor code, authorization category code, etc.) contained in anauthorization message. Rejections may also occur in response to invalidor corrupted authentication data included in the transaction data suchas an invalid Personal Identification Number (PIN), Card VerificationValue (CVV), Dynamic Card Verification Value (dCVV), cryptogram, orother authentication data. The authorization module 204 may include sucherror codes in the transaction data stored in the transaction database210. Transaction processing communication errors may also result in thegeneration of an error code. For example, if the server computer 202 isunable to communicate with one or more of the various payment processingentities (e.g., if an expected response is not received after adetermined period of time), the authorization module 204 may generate anappropriate error code for inclusion in the transaction data stored inthe transaction database 210. The authorization module 204 may alsodetermine transaction processing time details based upon time stampsincluded in authorization messages, and include such details in thestored transaction data.

The analytics module 206 may perform a number of functions related toanalyzing transaction data to determine whether a threshold has beenmet. For example, the analytics module 206 can periodically (e.g., every30 seconds, 1 minute, 5 minutes, 10 minutes, 30 minutes, hour, 12 hours,daily, weekly, etc.) access the transaction data stored in thetransaction database 210 and compare the transaction data with thresholddata stored for the various payment processing entities in the thresholddatabase 212. If the analytics module 206 determines that a thresholdhas been met, the analytics module 206 may create (or update) an eventrecord including the event data for the payment processing entity in theevent database 214. To determine whether to send an indication that thethreshold has been met to the payment processing entity, the analyticsmodule 206 may determine from the event record whether an indicationthat the threshold has been met was previously sent to the paymentprocessing entity. If no such indication was previously sent, theanalytics module 206 may transmit the event data to the alert module 208for providing an indication to the payment processing entity that thethreshold is now met. Alternatively, if the analytics module 206determines that the threshold has not been met, the analytics module 206may determine from the event record whether an indication that thethreshold has been met (e.g., that the threshold was previously met) waspreviously sent to the payment processing entity. If such an indicationwas previously sent, the analytics module 206 may transmit the eventdata to the alert module 208 for providing an indication to the paymentprocessing entity that the threshold is no longer met.

The alert module 208 may perform a number of functions relating totransmitting an indication that a threshold has been met to a paymentprocessing entity. For example, upon receiving event data from theanalytics module 206 (and/or retrieving event data from event database214), the alert module 208 may generate and send an indication that athreshold has (or has not been) met to the payment processing entity.The indication can include information regarding a performance parameterof the payment processing entity, and can be transmitted in any suitableelectronic form such as an e-mail message, text message, etc. Theindication can be transmitted by the alert module 208 over the samecommunication channel used to exchange authorization messages, or can betransmitted over the alternative communication channel 216.

As explained above, the transaction database 210 may store transactiondata including data extracted from authorization messages, error codesgenerated by the authorization module 204, transaction processing timedetails, and other information. In embodiments of the invention, thetransaction data may be stored in the transaction database 210 in theform of transaction data tables.

FIG. 3 shows a transaction data table 300 as stored in the transactiondatabase 210 according to an embodiment of the invention. As seen inFIG. 3, the transaction data table 300 may include various data fieldsincluding transaction data. For example, for individual transactions,the transaction data table 300 may include a Transaction ID Field 300(a)including a unique identifier for the transaction, a Date/Time Field300(b) including the date and time of the transaction, an Account NumberField 300(c) including the account number (or an encrypted accountnumber) used in the transaction (e.g., a credit, debit, ATM, or prepaidaccount number), a Transaction Class Field 300(d) including a codeidentifying the transaction as a credit, debit, prepaid, or ATMtransaction, or other type of transaction, a Merchant/ATM Field 300(e)including a code identifying a merchant (e.g., MVV, DBA, etc.) or an ATMinvolved in the transaction, an Acquirer Field 300(f) including a codeidentifying an acquirer involved in the transaction, an acquirerprocessor Field 300(g) including a code identifying an acquirerprocessor involved in the transaction, an Issuer Field 300(h) includinga code identifying an issuer used in the transaction, an IssuerProcessor Field 300(i) including a code identifying an issuer processorinvolved in the transaction, an Authorization Category Field 300(j)including a code identifying the authorization category (e.g., approved,declined, rejected, etc.) of the transaction, an Error Code Field 300(k)including a code identifying an error associated including theprocessing of the transaction, and a Transaction Amount Field 300(l)including the amount of the transaction if successfully processed.Transaction data table 300 can include other fields including additionalinformation such as cardholder or account holder information (e.g.,name, date of birth, address, phone number, etc.), card verificationvalue (CVV), expiration date, loyalty account information, and otherinformation relating to the transaction. Any suitable combination of thefields shown in transaction data table 300 may be used, and more, less,or different fields can be included according to embodiments of theinvention.

The threshold database 212 may store thresholds for the various paymentprocessing entities as threshold data. The threshold data may includevalues relating to the percentage of overall transactions associatedwith one or more performance parameters such as approved transactions,declined transactions, rejected transactions, transaction processingtime, transaction processing communication errors, etc. The thresholdvalues may be selected by the payment processing entities and/or may bebased on industry best practices, recommendations provided by thepayment processing network 118, etc. In some embodiments of theinvention, the threshold values may relate to payment processingstatistics for peer entities. For example, an acquirer may want to knowif their transactions are being declined at a higher rate than thetransactions of other acquirers. Thus, payment processing entities mayestablish dynamic thresholds that relate to a comparison of theirperformance parameters with other similarly situated entities. Inembodiments of the invention, the threshold data stored in the thresholddatabase 212 may be customizable by the payment processing entities. Forexample, a payment processing entity may access a web interface toselect threshold values, the particular performance parameters for whichthe entity wants to receive indications, the types of transactionclasses to be monitored, etc. In embodiments of the invention, thethreshold data may be stored in the threshold database 212 in the formof threshold data tables.

FIG. 4 shows a threshold data table 400 as stored in the thresholddatabase 212 according to an embodiment of the invention. As seen inFIG. 4, the threshold data table 400 may include various data fieldsincluding threshold data. For example, for individual payment processingentities, the threshold data table 400 may include a Payment ProcessingEntity Field 400(a) including a code identifying the payment processingentity (e.g., merchant code, acquirer code, acquirer processor code,issuer code, issuer processor code, etc.), a Transaction Class Field400(b) including codes identifying one or more transaction classes(e.g., credit, debit, prepaid, ATM, etc.), a Performance Parameter Field400(c) including one or more codes identifying performance parameters(e.g., approvals, declines, rejects, etc.) for each of the selectedtransaction classes, a Threshold % Field 400(d) including a thresholdvalue for each of the selected performance parameters, and any othersuitable data field. Any suitable combination of the fields shown inthreshold data table 400 may be used, and more, less, or differentfields can be included according to embodiments of the invention.

As explained above, the event database 214 may store event data for thevarious payment processing entities. The event data may be includetransaction data for transactions conducted during specific timeintervals, threshold data, and details regarding the transmission ofindications to the various payment processing entities. In embodimentsof the invention, the event data may be stored by the analytics module206 in the event database 214 and in the form of event data tables.

FIG. 5 shows an event data table 500 as stored in the event database 214according to an embodiment of the invention. As seen in FIG. 5, theevent data table 500 may include various data fields including eventdata. For example, for individual payment processing entities, the eventdata table 500 may include a Payment Processing Entity Field 500(a)including a code identifying the payment processing entity (e.g.,merchant code, acquirer code, acquirer processor code, issuer code,issuer processor code, etc.), a Time Interval Field 500(b) including thecurrent interval of time for which transaction data was analyzed, aTransaction Class Field 500(c) including codes identifying one or moretransaction classes (e.g., credit, debit, prepaid, ATM, etc.), a TotalTransaction Count Field 500(d) including the total number oftransactions for each selected transaction class during the timeinterval, a Performance Parameter Field 500(e) including one or morecodes identifying performance parameters (e.g., approvals, declines,rejects, etc.) for each of the selected transaction classes, aPerformance Parameter Count Field 500(f) including the total number oftransactions associated with each of the performance parameters duringthe time interval and for each selected transaction class, a PerformanceParameter % Field 500(g) including the percentage of transactionsassociated with each of the performance parameters during the timeinterval and for each selected transaction class, a Threshold % Field500(h) including threshold values for each of the selected performanceparameters as stored in the threshold database 212 for the paymentprocessing entities, a Threshold Met for Time Interval Field 500(i)including a code identifying whether a threshold has been met fortransactions conducted during the current interval of time, a ThresholdMet for Previous Time Interval Field 500(j) including a code identifyingwhether a threshold was met for previous transactions conducted during aprevious interval of time (e.g., whether an indication was previouslyprovided to a payment processing entity, a Date/Time of PreviousIndication Provided to Entity Field 500(k) including the date and timethat an indication was previously provided to a payment processingentity, and any other suitable data field. Any suitable combination ofthe fields shown in event data table 500 may be used, and more, less, ordifferent fields can be included according to embodiments of theinvention.

Upon a determination by the analytics module 206 that an indication isto be sent to a payment processing entity, the alert module 208 maygenerate the indication to include event data stored in event database214 and/or as provided by analytics module 206. If the analytics module206 determines that a threshold has been met for a payment processingentity (e.g., that the Performance Parameter % value 500(g) in eventdata table 500 is equal or greater than the Threshold % value 500(h)),and that a previous indication of the met threshold has not been sent(e.g., that the Threshold Met for Previous Time Interval Field 500(j) inevent data table 500 indicates that no previous indication was sent),then the alert module 208 may send the indication to the paymentprocessing entity in the form of an event alert message as shown in FIG.6. Upon sending the indication, alert module 208 may update the data inthe Alert Previously Submitted Field 500(i) to indicate that an alertwas previously sent to the payment processing entity.

In an embodiment of the invention, upon a determination that a thresholdhas been met and that a previous indication was not provided, anindication can be provided to the payment processing entity in the formof an event alert message 600 as shown in FIG. 6. As seen in FIG. 6, theevent alert message 600 may include information describing the identityof the recipient payment processing entity 600(a), the selectedtransaction class for which the threshold was exceeded 600(b), the timeinterval during which transaction data was analyzed 600(c), the selectedperformance parameter 600(d), the total number of transactionsassociated with the selected performance parameter 600(e), the totalnumber of transactions for the selected class during the time interval600(f), a percentage of transactions associated with the selectedperformance parameter during the time interval and for the selectedtransaction class 600(g), the stored threshold value for the selectedperformance parameter 600(h), and other information. In embodiments ofthe invention, more, less, or different information can be included inthe event alert message 600.

If the analytics module 206 determines that a threshold has not been metfor a payment processing entity (e.g., that the Performance Parameter %value 500(g) in event data table 500 is less than the Threshold % value500(h)), but also determines that an indication that the threshold waspreviously met was transmitted to the payment processing entity (e.g.,that the Threshold Met for Previous Time Interval Field 500(j) in eventdata table 500 indicates that a previous indication was sent), then thealert module 208 may send an indication to the payment processing entitythat the threshold is no longer met. The indication may be in the formof an event completion message as shown in FIG. 7.

In an embodiment of the invention, upon a determination that a thresholdhas not been met and that a previous indication was provided, anindication can be provided to the payment processing entity in the formof an event completion message 700 as shown in FIG. 7. As seen in FIG.7, the event completion message 700 may include information describingthe identity of the recipient payment processing entity 700(a), theselected transaction class for which the threshold is no longer exceeded700(b), the time interval during which transaction data was analyzed700(c), the selected performance parameter 700(d), the total number oftransactions associated with the selected performance parameter 700(e),the total number of transactions for the selected class during the timeinterval 700(f), the percentage of transactions associated with theselected performance parameter during the time interval and for theselected transaction class 700(g), the stored threshold value for theselected performance parameter 700(h), and other information. The eventcompletion message 700 may also include information summarizing theprevious event. For example, as seen in FIG. 7, the event completion mayinclude information describing the cumulative interval of time duringwhich the threshold was exceeded for the selected performance parameter700(i), the total number of transactions associated with the performanceparameter during the cumulative time interval 700(j), the total numberof transactions for the selected class during the cumulative timeinterval 700(k), the percentage of transactions associated with selectedperformance parameter during the cumulative time interval and for theselected class 700(l), and other information. In embodiments of theinvention, more, less, or different information can be included in theevent completion message 700.

In embodiments of the invention, the level of detail included in thevarious indications sent to the payment processing entities may vary.For example, a payment processing entity may customize the types ofinformation provided by the alert module 208 by accessing a webinterface and selecting a preferred level of detail. Entity preferencesmay be stored in any of the databases shown in FIG. 2, or in any othersuitable database communicatively coupled to the server computer 202.

Transaction data can be analyzed, thresholds established, andindications provided to payment processing entities at many differentlevels of detail. In embodiments of the invention, acquirers and issuersmay use different processors for different classes of transactions orgeographic regions. For example, an acquirer may use one acquirerprocessor for credit transactions and a different acquirer processor fordebit transactions. Similarly, an issuer processor may use one issuerprocessor for credit transactions and a different issuer processor fordebit transactions. In another example, acquirers or issuers may use oneprocessor for transactions conducted in a particular geographic regionand a different processor for transactions conducted in anothergeographic region. Thus, the transaction data stored in the transactiondatabase 210, the threshold data stored in the threshold database 212,and/or the event data stored in the event database 214 may includedetails at the individual processor or geographic level. For example, apayment processing entity may select specific thresholds fortransactions processed by particular issuer or acquirer processors,and/or for transactions conducted in particular geographic regions. Theindications generated by the alert module 208 (e.g., the event alertmessage 600 of FIG. 6 and the event completion message 700 of FIG. 7)may include information at the processor and/or geographic level. Insome embodiments of the invention, the server computer 202 of thepayment processing network 118 may comprise multiple server computerslocated at different locations (e.g., processing centers). For example,each server computer may be in communication with a separate set ofdatabases such as those shown in FIG. 2. The data stored in thesedatabases may be redundant across the various processing centers ornon-redundant in embodiments of the invention. In either case, thestored transaction data, threshold data, and/or event data may includedetails at the individual processing center level (e.g., processingcenter codes). Thus, the indications generated by the alert module 208may also include information at the processing center level.

II. Exemplary Methods

FIG. 8 illustrates a flow diagram showing a method 800 for monitoringtransaction data and providing an indication regarding a performanceparameter to a payment processing entity according to an embodiment ofthe invention. The steps performed in the method 800 can be performed,for example, by the server computer 202 shown in FIG. 2. In otherembodiments of the invention, one or more steps of the method 800 may beperformed by any other suitable computer system, such as the issuercomputer 120, acquirer computer 116, an issuer processor computer, anacquirer processor computer, or other suitable computer system.

At step 802, the method 800 may begin by the server computer 202receiving transaction data associated with a plurality of transactionsconducted during a time interval. The time interval can be apredetermined increment of time, and can be established by the paymentprocessing network or any of the other payment processing entities. Asdescribed herein, the transaction data may comprise data contained inauthorization request messages received from the acquirer computer 116,data contained in an authorization response messages received from theissuer computer 120, error codes generated by the server computer 202 inresponse to rejected authorization messages, error codes generated bythe server computer 202 in response to transaction processingcommunication errors with one or more of the payment processing entitiesinvolved in the transaction, information regarding transactionprocessing time for transactions, and other transaction data. Uponreceipt, the transaction data may be stored by authorization module 204in transaction database 210. To illustrate, the transaction datareceived by the server computer 202 may indicate that a merchant hasconducted 100 transactions in the last 5 minutes, and that 28 of thetransactions were declined by issuers due to an invalid PIN code beingtransmitted with the authorization request messages. Upon receipt of thetransaction data, the method 800 can then proceed to decision 804.

At decision 804, the analytics module 206 may determine whether thereceived transaction data meets a threshold. For example, the analyticsmodule 206 can periodically access the transaction data stored in thetransaction database 210 and compare the transaction data against thethreshold data stored in the threshold database 212. As describedherein, the thresholds may be predetermined and the threshold data mayinclude values relating to the percentage of overall transactionsassociated with one or more performance parameters such as approvedtransactions, declined transactions, rejected transactions, transactionprocessing time, transaction processing communication errors, etc. Thethreshold values may be selected by the payment processing entitiesand/or may be based on industry best practices, recommendations providedby the payment processing network 118, etc. In some embodiments of theinvention, the threshold values may be dynamic and relate to paymentprocessing statistics for peer entities. In embodiments of theinvention, the threshold data stored in the threshold database 212 maybe customizable by the payment processing entities. For example, apayment processing entity may access a web interface to select thresholdvalues, the particular performance parameters for which the entity wantsto receive indications, the types of transaction classes to bemonitored, etc. At decision 804, the analytics module 206 may comparereceived transaction data to the stored thresholds for the paymentprocessing entities. For example, referring back to the aboveillustration, the merchant may have established a threshold of 25% fortransactions declined due to an invalid PIN, and the analytics module206 may compare the merchant's transaction data with the storedthreshold to determine that 28 of the merchant's 100 transactions (e.g.,28%) were declined due to an invalid PIN in the last 5 minutes, and thatthe merchant's 25% threshold has therefore been met. Upon determiningthat the threshold has been met, the method 800 may proceed to decision806.

The analytics module 206, at decision 806, may determine whether thethreshold was previously met by transaction data received fortransactions conducted during a previous time interval, and thus whetheran indication was already provided to the payment processing entity. Forexample, the analytics module 206 may access the event data stored inthe event database 214 to determine whether the threshold was previouslymet, and thus whether an indication (e.g., event alert message 600 ofFIG. 6) was previously provided to the payment processing entity.Referring back to the above illustration, the analytics module 206 maydetermine that more than 25% of the merchant's previous transactions,conducted during the previous time interval, were declined by issuersdue to an invalid PIN. As described herein, the merchant may not want toreceive redundant event alert messages regarding the high occurrence ofinvalid PIN entries since the merchant is already aware of the issue,and the payment processing network may not want to generate redundantevent alert messages since this is computationally inefficient. As such,once it is determined by the analytics module 206 that the 25% thresholdwas met by previous declined transactions, and that an event alertmessage was already transmitted to the merchant, the analytics module206 may not send a further alert regarding the same issue. The method800 may then return to step 802 wherein transaction data for subsequenttransactions (i.e. for transactions conducted during subsequent timeintervals) may be received by the server computer 202 and analyzed. Ifit is determined, however, that a previous indication was nottransmitted to the payment processing entity, then the method mayproceed to step 808.

At step 808, the alert module 208 may transmit an indication that thethreshold has been met to the payment processing entity, the indicationincluding information regarding the performance parameter of the paymentprocessing entity. For example, referring back to the aboveillustration, the alert module 208 may transmit an indication (e.g., theevent alert message 600 of FIG. 6) to the merchant. As shown in FIG. 6,the event alert message 600 may inform the merchant that in the current5 minute time interval, 28 of the merchant's 100 transactions (i.e. 28%)were declined by issuers due to an invalid PIN, and that this met themerchant's established threshold of 25%. In response to receiving theevent alert message 600, the merchant may be able to investigate whetherthe high occurrence of declined transactions is due to hardware and/orsoftware issues, and make any needed repairs in a timely manner. Uponsending the indication, the alert module 208 (or analytics module 206)may update the event data for the payment processing entity stored inthe event database 214 to reflect that the indication was transmitted tothe payment processing entity (e.g., Field 500(j) of Event Data Table500 shown in FIG. 5), thereby preventing redundant indications frombeing transmitted for transactions conducted during subsequent timeintervals. Upon sending the indication and updating the event data forthe payment processing entity, the method 800 may then return to step802 wherein transaction data for subsequent transactions (i.e. fortransactions conducted during subsequent time intervals) may be receivedby the server computer 202 and analyzed.

Returning to decision 804, upon receiving the transaction data for theplurality of transactions conducted during the current time interval,the analytics module 206 may alternatively determine that the thresholdis not met. For example, referring back to the above illustration, thetransaction data received by the server computer 202 may insteadindicate the merchant has conducted 125 transactions in the last 5minutes, and that 25 of the transactions (e.g., 20%) were declined byissuer due to an invalid PIN code being transmitted with theauthorization request message. The analytics module 206 may compare thistransaction data with the merchant's established threshold of 25%, anddetermine that the threshold is not met. Once it is determined that thereceived transaction data does not meet the threshold, the method 800may proceed to decision 810.

At decision 810, the analytics module 206 may determine whether thethreshold was previously met by transaction data received fortransactions conducted during a previous time interval, and thus whetheran indication was previously provided to the payment processing entity.For example, the analytics module 206 may access the event data storedin the event database 214 to determine whether the threshold waspreviously met, and thus whether an indication (e.g., event alertmessage 600 of FIG. 6) was previously provided to the payment processingentity. For example, referring back to the above illustration, theanalytics module 206 may determine that the merchant's 25% threshold wasnot previously met by transaction data for transactions conducted duringa previous time interval. Since the merchant's threshold was not met fortransactions conducted during the current or previous time interval, thealert module 208 may send no indication to the merchant regardingtransactions declined due to PIN entry errors, and the method 800 mayreturn to step 802 wherein transaction data for subsequent transactionsmay be received by the server computer 202 and analyzed.

At decision 810, the analytics module 206 may alternatively determinethat the threshold was previously met by transaction data received fortransactions conducted during a previous time interval, and that that anindication was previously provided to the payment processing entity. Forexample, the analytics module 206 may access the event data stored inthe event database 214 and determine that the threshold was previouslymet, and that an indication (e.g., the alert message 600 of FIG. 6) waspreviously provided to the payment processing entity. Referring back tothe above illustration, the analytics module 206 may determine thatalthough the threshold is not met for the merchant's transactionsconducted during the current time interval, the threshold was met for aprevious time interval, and thus an indication (e.g., the alert message600 of FIG. 6) was previously provided to the merchant. The method maythen proceed to step 812.

Although payment processing entities may not want to receive redundantindications regarding the same potential hardware or software problems,they may want to be notified that a previously detected issue appears tohave been resolved. At step 812, in response to determining that thethreshold is no longer met for the payment processing entity, the alertmodule 208 may transmit an indication that the threshold is no longermet to the payment processing entity, the indication includinginformation regarding the performance parameter of the paymentprocessing entity. For example, referring back to the aboveillustration, the alert module 208 may provide an indication (e.g., theevent completion message 700 as shown in FIG. 7) to the merchant. Asshown in FIG. 7, the event completion message 700 may inform themerchant that in the current 5 minute time interval, 25 of themerchant's 125 transactions (e.g., 20%) were declined by issuers due toan invalid PIN, and that the merchant's established threshold of 25% isno longer met. This may indicate to the merchant the previous softwareor hardware issue has been resolved.

Payment processing entities may also be provided with a summary of theprevious event after it is determined that a threshold is no longer met.For example, analytics module 206 may determine event statistics such asthe total number of time intervals (e.g., the cumulative span of time)during which the threshold was exceeded, and other statistics regardingthe event. As seen in FIG. 7, the event completion message 700 may alsoinclude the cumulative time interval 7010(i) of the previous event, thetotal number of transactions associated with the performance parameterduring the cumulative time interval 700(j), the total number of overalltransactions during the cumulative time interval 700(k), the totalpercentage of overall transactions associated with the performanceparameter during the cumulative time interval 700(l), and otherinformation.

In embodiments of the invention, the analytics module 206 may alsoconsider thresholds relating to overall transaction count in making adetermination whether to provide an indication to a payment processingentity. For example, the threshold database 212 (or any other databaseshown in FIG. 2) may store thresholds relating to a minimum number oftotal transactions that must be processed before an indication isprovided. A low number of transactions (i.e. a small sample size) mayresult in “false positives.” In these situations, an indicationregarding a performance parameter may be sent to a payment processingentity even though a larger number of transactions would not havetriggered the indication. By requiring a minimum number of transactionsbefore providing an indication, such false positives may be reduced.Thresholds relating to overall transaction count may be selected bypayment processing entities and/or determined by best practices,recommendations by the payment processing network 118, etc.

Threshold values may change depending on the time of day in someembodiments of the invention. For example, some merchants mayconsistently experience an increased occurrence of declined transactionsat nighttime as compared to other times of the day. Thus, if a thresholdrelates to the percentage of overall transactions that are declined, themerchant may elect to increase the threshold value during the nighttimeto avoid false positives. Such dynamic thresholds may be selected by thepayment processing entity, determined by best practices, etc.

Payment processing entities way also want alerts and/or reportsincluding overall performance parameter statistics even if theirselected thresholds have not been met. In embodiments of the invention,such alerts and reports may be provided by the server computer 202 tothe various payment processing entities. For example, alert module 208may transmit a “wellness alert” to a payment processing entity on aperiodic basis (e.g., twice a day, daily, weekly, monthly etc.)including statistics regarding approved transaction, declinedtransactions, transaction processing time, communication errors, etc.Such wellness alerts may include a comparison of an entity's performanceparameter statistics with those of similarly situated entities (e.g.,similar function, size, geographic region, etc.), or a comparison withthe entity's own historical statistics. Wellness alerts may providepayment processing entities with confirmation that their transactionprocessing hardware and software are functioning correctly, and mayenable entities to analyze transaction processing trends over time.

Embodiments of the invention provide a number of technical advantagesover existing computational solutions to the problem of detectinghardware and software failures at a payment processing entity. Forexample, by providing an indication that a threshold has been met onlyif an indication was not previously provided to the payment processingentity, computing resources may be preserved. Alert messages requirememory and processing power to generate and send, and by reducing thesemessages, embodiments of the invention provide for a more efficient andless memory-intensive solution.

Moreover, embodiments of the invention provide a number of businessadvantages over existing solutions. For example, redundant alertsregarding the same payment processing issue may be distracting andfrustrating for payment processing entities, and may result in aninefficient use of the entity's resources. A payment processing entitymust typically use personnel and computer resources to monitor, process,and act on alerts regarding processing issues. Thus, once an entity ismade aware of a particular issue, further alerts regarding the sameprocessing issue may result in an efficient use of the entity'sresources. Redundant alerts may also result in a scenario where alertmessages are ignored by the entity, and a new alert regarding anunrelated processing issue may not be acted on. By providing anindication that a threshold has been met only if an indication was notpreviously provided to the payment processing entity, the entity'sbusiness resources may be used more efficiently and effectively.Further, payment processing entities typically earn revenue on a pertransaction basis, and rejected or declined transactions often result inlost sales to merchants, lost switch fees to payment processingnetworks, and lost interchange revenue to issuers, acquirers, andprocessors. In other words, rejected or declined transactions may resultin lost revenue for all payment processing entities involved. Byaccurately and efficiently detecting unusually high occurrences of thevarious performance parameters described herein, and by providing promptnotification of such occurrences, payment processing entities may bebetter equipped to identify and repair hardware or software failures ina timely manner.

III. Exemplary Portable Consumer Devices, Access Devices, and ComputerApparatuses

FIGS. 9A-9B show block diagrams of exemplary portable consumer devicesaccording to embodiments of the invention.

FIG. 9A shows a block diagram of a phone 112′ that can be used inembodiments of the invention. The phone 112′ can be both a notificationdevice that can receive alert messages, as well as a portable devicethat can be used to make payments. The exemplary phone 112′ may comprisea computer readable medium 112(b) and a body 112(h) as shown in FIG. 9A.The computer readable medium 112(b) may be in the form of (or may beincluded in) a memory that stores transaction data (e.g., issuer accountnumbers, loyalty provider account numbers, etc.) and may be in anysuitable form including a magnetic stripe, a memory chip, etc. Thememory may store information such as financial information, transitinformation (e.g., as in a subway or train pass), access information(e.g., as in access badges), etc. Financial information may includeinformation such as bank account information, loyalty accountinformation (e.g., a loyalty account number), an issuing bankidentification number (BIN), credit or debit card number information,account balance information, an expiration date, consumer informationsuch as the account holder's name, date of birth, etc. Any of thisinformation may be transmitted by the phone 112′.

In some embodiments, information in the memory may also be in the formof data tracks that are traditionally associated with credit cards. Suchtracks may include Track 1 and Track 2. Track 1 (“International AirTransport Association”) may store more information than Track 2, and maycontain the cardholder's name as well as account number and otherdiscretionary data. This track is sometimes used by the airlines whensecuring reservations with a credit card. Track 2 (“American BankingAssociation”) is currently most commonly used. This is the track that isread by ATMs and credit card checkers. The ABA (American BankingAssociation) designed the specifications of this track and all worldbanks abide by it. It contains the cardholder's account, encrypted PIN,plus other discretionary data.

The phone 112′ may further include a contactless element 112(g), whichmay be implemented in the form of a semiconductor chip (or other datastorage element) with an associated wireless transfer (e.g., datatransmission) element, such as an antenna. The contactless element112(g) may be associated with (e.g., embedded within) the phone 112′ anddata or control instructions transmitted via a cellular network may beapplied to the contactless element 112(g) by means of a contactlesselement interface (not shown). The contactless element interface mayfunction to permit the exchange of data and/or control instructionsbetween the mobile device circuitry (and hence the cellular network) andthe optional contactless element 112(g).

The contactless element 112(g) may be capable of transferring andreceiving data using a near field communications (“NFC”) capability (ornear field communications medium) in accordance with a standardizedprotocol or data transfer mechanism (e.g., ISO 14443/NFC). Near fieldcommunications capability is a short-range communications capability,such as RFID, Bluetooth™, infra-red, or other data transfer capabilitythat can be used to exchange data between the phone 112′ and aninterrogation device. Thus, the phone 112′ may be capable ofcommunicating and transferring data and/or control instructions via botha cellular network and near field communications capability.

The phone 112′ may also include a processor 112(c) (e.g., amicroprocessor) for processing the functions of the phone 112′ and adisplay 112(d) to allow a consumer to see the phone numbers and otherinformation and messages. The phone 112′ may further include inputelements 112(e) to allow a user to input information into the device, aspeaker 112(f) to allow the user to hear voice communication, music,etc., and a microphone 112(i) to allow the user to transmit her voicethrough the phone 112′. The phone 112′ may also include an antenna112(a) for wireless data transfer (e.g., data transmission).

If the portable consumer device is in the form of a debit, credit, orsmartcard, the portable consumer device may also optionally havefeatures such as magnetic strips. Such devices can operate in either acontact or contactless mode.

An example of a portable consumer device 112″ in the form of a card isshown in FIG. 9B. FIG. 9B shows a plastic substrate 112(m). Acontactless element 112(o) for interfacing with an access device may bepresent on or embedded within the plastic substrate 112(m). Consumerinformation 112(p) such as an account number, expiration date, and username may be printed or embossed on the card. Also, a magnetic stripe112(n) may also be on the plastic substrate 112(m). The portableconsumer device 112″ may also comprise a microprocessor and/or memorychips with user data stored in them.

As shown in FIG. 9B, the portable consumer device 112″ may include botha magnetic stripe 112(n) and a contactless element 112(o). In otherembodiments, both the magnetic stripe 112(n) and the contactless element112(o) may be in the portable consumer device 112″. In otherembodiments, either the magnetic stripe 112(n) or the contactlesselement 112(o) may be present in the portable consumer device 112″.

FIG. 10 shows a block diagram of an exemplary access device 1002according to an embodiment of the invention.

As shown in FIG. 10, the access device 1002 may comprise a processor1002(a). It may also comprise a computer readable medium 1002(b), a cardreader 1002(c), a memory 1002(d), a network interface 1002(e), an outputdevice 1002(f), a capture file generation module 1002(g), and amessaging module 1002(h), all operatively coupled to the processor1002(a). A housing may house one or more of these components. The cardreader 1002(c) of access device 1002 may include one or more radiofrequency (RF) antennas, magnetic stripe readers, etc., that caninteract with a portable consumer device such as portable consumerdevices 112′ and 112″ shown in FIGS. 9A-9B. Suitable output devices1002(f) may include displays and audio output devices. Exemplarycomputer readable media 1002(b) may include one or more memory chips,disk drives, etc.

FIG. 11 shows a block diagram of a computer apparatus according to anembodiment of the invention.

The various participants and elements may operate one or more computerapparatuses (e.g., server computers) to facilitate the functionsdescribed herein, and any of the elements in the figures may use anysuitable number of subsystems to facilitate the functions describedherein. Examples of such subsystems or components are shown in FIG. 11.The subsystems shown in FIG. 11 are interconnected via a system bus1175. Additional subsystems such as a printer 1174, keyboard 1178, fixeddisk 1179 (or other memory comprising computer readable media), monitor1176, which is coupled to display adapter 1182, and others are shown.Peripherals and input/output (I/O) devices, which couple to I/Ocontroller 1171, can be connected to the computer system by any numberof means known in the art, such as serial port 1177. For example, serialport 1177 or external interface 1181 can be used to connect the computerapparatus to a wide area network such as the Internet, a mouse inputdevice, or a scanner. The interconnection via system bus 1175 may allowthe central processor 1173 to communicate with each subsystem and tocontrol the execution of instructions from the system memory 1172 or thefixed disk 1179, as well as the exchange of information betweensubsystems. The system memory 1172 and/or the fixed disk 1179 may embodya computer readable medium.

Further, while the present invention has been described using aparticular combination of hardware and software in the form of controllogic and programming code and instructions, it should be recognizedthat other combinations of hardware and software are also within thescope of the present invention. The present invention may be implementedonly in hardware, or only in software, or using combinations thereof.

The software components or functions described in this application maybe implemented as software code to be executed by one or more processorsusing any suitable computer language such as, for example, Java, C++ orPerl using, for example, conventional or object-oriented techniques. Thesoftware code may be stored as a series of instructions, or commands ona computer-readable medium, such as a random access memory (RAM), aread-only memory (ROM), a magnetic medium such as a hard-drive or afloppy disk, or an optical medium such as a CD-ROM. Any suchcomputer-readable medium may also reside on or within a singlecomputational apparatus, and may be present on or within differentcomputational apparatuses within a system or network.

The present invention can be implemented in the form of control logic insoftware or hardware or a combination of both. The control logic may bestored in an information storage medium as a plurality of instructionsadapted to direct an information processing device to perform a set ofsteps disclosed in embodiments of the present invention. Based on thedisclosure and teachings provided herein, a person of ordinary skill inthe art will appreciate other ways and/or methods to implement thepresent invention.

Some embodiments of the invention may be directed to a methodcomprising: receiving transaction data associated with a plurality oftransactions conducted during a time interval; storing in a first datatable, threshold data associated with corresponding transaction types;storing in a second data table, event data indicating whether athreshold has been met for previous transaction conducted during aprevious time interval; determining, based on the first data table,whether a threshold associated with a transaction type of the receivedtransaction data has been met by the transaction data associated withthe plurality of transactions conducted during the time interval;detecting, based on the second data table, whether a previous indicationthat the threshold has been met was signaled to a payment processingentity; and signaling an indication that the threshold has been met tothe payment processing entity only if no previous indication has beendetected.

It is understood that the examples and embodiments described herein arefor illustrative purposes only and that various modifications or changesin light thereof will be suggested to persons skilled in the art and areto be included within the spirit and purview of this application andscope of the appended claims. All publications, patents, and patentapplications cited in this patent are hereby incorporated by referencefor all purposes.

One or more features from any embodiment may be combined with one ormore features of any other embodiment without departing from the scopeof the disclosure.

In embodiments, any of the entities described herein may be embodied bya computer that performs any or all of the functions and stepsdisclosed.

Any recitation of “a”, “an” or “the” is intended to mean “one or more”unless specifically indicated to the contrary.

The above description is illustrative and is not restrictive. Manyvariations of the invention will become apparent to those skilled in theart upon review of the disclosure. The scope of the invention should,therefore, be determined not with reference to the above description,but instead should be determined with reference to the pending claimsalong with their full scope or equivalents.

What is claimed is:
 1. A method comprising: receiving transaction dataassociated with a plurality of transactions conducted during a timeinterval; determining, by a server computer, that the receivedtransaction data meets a threshold; determining whether a previousindication that the threshold has been met was provided to a paymentprocessing entity, the previous indication being associated with aplurality of previous transactions conducted during a previous timeinterval; and if the previous indication was not provided, providing anindication that the threshold has been met to the payment processingentity, the indication including information regarding a performanceparameter of the payment processing entity.
 2. The method of claim 1,wherein the time interval is a first time interval, and wherein themethod further comprises: after providing the indication, receivingtransaction data associated with a plurality of subsequent transactionsconducted during a second time interval; determining, by the servercomputer, that the received transaction data for the plurality ofsubsequent transactions does not meet the threshold; and providing anindication that the threshold has not been met to the payment processingentity, the indication including information regarding the performanceparameter of the payment processing entity.
 3. The method of claim 1,wherein the payment processing entity comprises a merchant, a paymentprocessor, an acquirer, or an issuer.
 4. The method of claim 1, whereinthe performance parameter is associated with approved transactions,declined transactions, rejected transactions, transaction processingtime, or transaction processing communication errors.
 5. The method ofclaim 1, wherein the time interval is a predetermined increment of time.6. The method of claim 1, wherein the threshold is a predetermined valueor a dynamic value.
 7. The method of claim 1, wherein providing theindication includes providing an alert message to the payment processingentity.
 8. A server computer comprising: a processor; and a computerreadable medium coupled to the processor, wherein the computer readablemedium comprises code executable by a processor for implementing amethod comprising: receiving transaction data associated with aplurality of transactions conducted during a time interval; determining,by a server computer, that the received transaction data meets athreshold; determining whether a previous indication that the thresholdhas been met was provided to a payment processing entity, the previousindication being associated with a plurality of previous transactionsconducted during a previous time interval; and if the previousindication was not provided, providing an indication that the thresholdhas been met to the payment processing entity, the indication includinginformation regarding a performance parameter of the payment processingentity.
 9. The server computer of claim 8, wherein the time interval isa first time interval, and wherein the computer readable medium furthercomprises code executable by the processor for implementing a methodcomprising: after providing the indication, receiving transaction dataassociated with a plurality of subsequent transactions conducted duringa second time interval; determining, by the server computer, that thereceived transaction data for the plurality of subsequent transactionsdoes not meet the threshold; and providing an indication that thethreshold has not been met to the payment processing entity, theindication including information regarding the performance parameter ofthe payment processing entity.
 10. The server computer of claim 8,wherein the payment processing entity comprises a merchant, a paymentprocessor, an acquirer, or an issuer.
 11. The server computer of claim8, wherein the performance parameter is associated with approvedtransactions, declined transactions, rejected transactions, transactionprocessing time, or transaction processing communication errors.
 12. Theserver computer of claim 8, wherein the time interval is a predeterminedincrement of time.
 13. The server computer of claim 8, wherein thethreshold is a predetermined value or a dynamic value.
 14. The servercomputer of claim 8, wherein providing the indication includes providingan alert message to the payment processing entity.
 15. A methodcomprising: transmitting, by a payment processing entity, transactiondata associated with a plurality of transactions conducted during a timeinterval to a server computer associated with a payment processingnetwork, wherein the server computer determines that the transmittedtransaction data meets a threshold, and wherein the server computerdetermines whether a previous indication that the threshold has been metwas provided to the payment processing entity, the previous indicationbeing associated with a plurality of previous transactions conductedduring a previous time interval; and if the previous indication was notprovided, receiving, from the server computer, an indication that thethreshold has been met, the indication including information regarding aperformance parameter of the payment processing entity.
 16. The methodof claim 15, wherein the time interval is a first time interval, andwherein the method further comprises: after receiving the indication,transmitting transaction data associated with a plurality of subsequenttransactions conducted during a second time interval to the servercomputer associated with the payment processing network, wherein theserver computer determines that the transmitted transaction data for theplurality of subsequent transactions does not meet the threshold; andreceiving, from the server computer, an indication that the thresholdhas not been met, the indication including information regarding theperformance parameter of the payment processing entity
 17. The method ofclaim 15, wherein the payment processing entity comprises a merchant, apayment processor, an acquirer, or an issuer.
 18. The method of claim15, wherein the performance parameter is associated with approvedtransactions, declined transactions, rejected transactions, transactionprocessing time, or transaction processing communication errors.
 19. Themethod of claim 15, wherein the time interval is a predeterminedincrement of time.
 20. The method of claim 15, wherein the threshold isa predetermined value or a dynamic value.
 21. The method of claim 15,wherein receiving the indication includes receiving an alert messagefrom the compute associated with the payment processing network.